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The private trading exchange (PTX) is 
emerging as the cornerstone of business-to- 
business e-commerce. At its core, a private 
trading exchange involves interenterprise 
integration and collaboration. Our main 
objective in this paper is to introduce a 
versatile application platform for building 
private trading exchanges. This platform 
supports the management and execution of 
multienterprise business processes and 
collaborations in the context of these 
processes. We review the business 
requirements of PTX-based systems and the 
technical challenges in developing such 
systems. We then examine and categorize the 
main interaction patterns between the private 
trading exchange and its participants. These 
patterns lead to the design of a component 
framework for process brokering and content 
aggregation. This framework is the foundation 
of our application platform for building PTX 
solutions. We describe the platform and 
discuss how to use it to implement a PTX 
solution. 


Private trading exchanges (PTXs) are emerging as the 
cornerstones of business-to-business e-commerce. 
AMR Research describes the PTX as “an application 
platform on which a company builds its trading in¬ 
terface to both suppliers and customers via Inter¬ 
net.” They predict the PTX market to garner $5.7 tril¬ 
lion in commerce transacted via the Internet by 2004, 
easily surpassing public and consortium exchange 
markets. 1 


How do private trading exchanges differ from other 
application platforms? What are the functional and 
nonfunctional requirements of private trading ex¬ 
changes? What are the technical challenges in re¬ 
alizing such a platform? How can we build a versa¬ 
tile application platform for private trading exchange 
solutions that addresses these challenges? These are 
some of the questions we try to answer in this pa¬ 
per. 

The heart of a private trading exchange solution is 
interenterprise integration and collaboration. An ap¬ 
plication platform for private trading exchange so¬ 
lutions should provide support for managing and ex¬ 
ecuting multienterprise business processes. It should 
help the employees and trading partners of a com¬ 
pany to collaborate, in the context of these business 
processes. Effective business process execution re¬ 
quires enterprise application integration as well. The 
platform should support “best-of-breed” application 
integration, since it is most likely that the diverse ap¬ 
plications of an enterprise come from multiple in¬ 
dependent software vendors (iSVs). Other require¬ 
ments include an integrated user interface, common 
security mechanisms, and solution management and 
monitoring. 

A key nonfunctional requirement is the ability of the 
platform to adapt to rapidly changing business con¬ 
ditions: new marketplaces and exchanges need to be 
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integrated; new protocols and messaging standards 
must be supported; and new trading partners and 
service providers should be discovered dynamically. 
Other nonfunctional requirements include perfor¬ 
mance and scalability, reliability and availability, and 
extensibility. 

We describe the design and implementation of an 
application platform that meets these requirements. 
Based on the requirements and use cases, we have 
identified the fundamental design patterns that are 
applicable in building a PTX solution. We used these 
patterns to develop a component framework that 
serves as the foundation of the platform. Here we 
focus primarily on two key modules in the platform, 
the business flow manager that orchestrates multi¬ 
enterprise business processes and the interaction 
manager that manages client interactions with the 
exchange. We discuss the current realization of the 
platform, which uses distributed object technology 
and off-the-shelf middleware. 

The paper is organized as follows. In the next sec¬ 
tion, we discuss the business requirements of busi- 
ness-to-business e-commerce solutions based on the 
PTX concept and identify the platform requirements. 
In the following section, we position our work in con¬ 
text by surveying related work in this area. We then 
relate the requirements to a set of patterns that char¬ 
acterize and categorize the interactions between a 
company’s private trading exchange and its trading 
partners. This leads to a discussion of the process 
broker framework and its application in realizing the 
platform. We describe an implementation of the plat¬ 
form based on WebSphere* Business Integrator. 2 
We then describe an innovative solution assembly 
methodology for building a PTX solution using this 
platform. At the heart of this methodology is a PTX 
solution template, which provides a skeleton to build 
customized PTX instances, allowing rapid develop¬ 
ment and deployment. We use a sample PTX solu¬ 
tion to present a concrete example of the cus¬ 
tomized platform. We then revisit the platform 
requirements and summarize our experience in us¬ 
ing the platform with customers. We conclude with 
future directions of work in this area. 

Requirement and challenges 

The PTX is a trade exchange hosted by a single com¬ 
pany to facilitate collaborative e-commerce with its 
trading partners. Concerned with the generic nature 
of public e-marketplaces, a company might develop 
and host a private exchange in order to gain control 


over who may participate, in what manner, how they 
may be connected, what contents should be pre¬ 
sented, and to whom, among many other issues. 3-5 
The PTX must support the complex relationships the 
company may have with its trading partners, rang¬ 
ing from tightly coupled partners in the supply chain 
processes, to loosely related “spot” buyers and sup¬ 
pliers from e-commerce portals. The ultimate goal 
might be to improve supply chain efficiencies and re¬ 
sponsiveness through improved process visibility and 
collaboration, advanced integration platforms, and 
customization capabilities. 

At an early stage of a company’s e-commerce efforts, 
external connectivity is the main concern. Early ef¬ 
forts usually result in establishing message-centric 
and transaction-oriented links with trading partners. 
Clearly, this is not enough to support the richer in¬ 
terenterprise process collaboration that might be re¬ 
quired. For process collaboration, the participants, 
at minimum, should have the ability to monitor the 
states of the transactions and manage their transi¬ 
tions. There are basic requirements that differenti¬ 
ate a private exchange from other forms of trade ex¬ 
changes. 

Direct access, control, and connectivity: A PTX should 
allow the hosting firm to deal with its customers or 
suppliers more directly and securely, and to control 
which partners see what data and perform which 
functions. The PTX platform should support the dif¬ 
ferent access rights of its participants, mirroring those 
of the trading relationships with the hosting firm. In 
addition, the PTX platform should permit the coexis¬ 
tence of multiple connection methods, reflecting the 
existing or emerging connectivity patterns preferred 
by the host firm’s trading partners. Many of the pub¬ 
lic exchanges, in contrast, promote the use of stan¬ 
dard communication protocols and transport mech¬ 
anisms specific to their particular industries. 

Sensitive data sharing with select partners: A PTX 
should be able to reveal sensitive price and inven¬ 
tory information to chosen customers and suppliers. 
For instance, component consumption information 
may be shared with certain suppliers as part of ven¬ 
dor-managed inventory agreements. 

Enriched buy and sell capabilities: A PTX should also 
allow the firm to sell products based on features other 
than price, by providing additional information to 
potential buyers. For instance, products bundled with 
additional service agreements may increase the to- 
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tal profit margins. This type of bundling can be more 
effective in a private exchange setting. 

Business agreement-based collaboration: A PTX should 
provide real-time connectivity and collaboration with 
trading partners, reflecting and supporting supply- 
chain agreements. 

Customizable services and processes: A PTX should 
allow a high degree of customer collaboration and 
provide the ability to customize services and tech¬ 
nology to a firm’s specific supply chain needs and 
trading relationships. 

Event- and trigger-driven processing: A PTX should 
pass efficiencies along the supply chain through fur¬ 
ther analysis of sensitive data. For instance, it can 
flag problems involved in a specific supply pipeline, 
such as too many components ordered, allowing 
faster and automated resolution. Private exchanges 
should be able to handle a richer set of events and 
triggers than public exchanges, because they have 
better access to the process and organizational de¬ 
tails of the host companies’ portion of the supply 
chains. 

These requirements entail the following platform 
characteristics (PCs): 

• Process collaboration (pci): A PTX should allow 
the employees and trading partners of a company 
to collaborate in the context of various business 
processes. 

• Application integration (PC2): Effective business 
process execution requires enterprise application 
integration as well. The platform should support 
application integration, because it is likely that the 
diverse applications of the firm come from mul¬ 
tiple ISVs. 

• Integrated user interface (PC3): The integrated user 
interface with role-based rendering is another ba¬ 
sic platform characteristic of the PTX platform. This 
is to ensure the uniformity of the user interface 
and its integration with the PTX server components. 

• Common and customizable security mechanisms 
(PC4): The security mechanisms should be customi¬ 
zable, supporting a large variety of collaborative 
relationships while maintaining commonality in 
terms of security component administration. 

• Solution management and monitoring (PC5): The 
PTX administration component must meet business 
control requirements and handle errors and excep¬ 
tions during operations. 


Table 1 shows how the PTX requirements are ad¬ 
dressed by the platform design characteristics. In ad¬ 
dition to the functional requirements, there are sev¬ 
eral nonfunctional requirements. These include the 
ability of the platform to adapt to rapidly changing 
business conditions (e.g., the integration with other 
exchanges, support for new protocols and messag¬ 
ing standards, and dynamic discovery of trading part¬ 
ners and service providers), performance and seal- 
ability, reliability and availability, and extensibility. 

Related work. Even though the PTX is a relatively 
new phenomenon, many of the underlying technol¬ 
ogies for PTX platforms have been developed and 
used over many years (some may even date back 
more than a decade, e.g., electronic data interchange 
[edi]). We examine related work in three key sup¬ 
porting technologies of a PTX platform to help clar¬ 
ify the distinctive features of the platform proposed 
in this paper. 

First, we discuss interenterprise connectivity. At one 
point, EDI was the only means by which businesses 
exchanged structured data, using value-added net¬ 
works (VANs). The appeal of conducting business 
over the Internet caused companies to look toward 
Internet-based interenterprise platforms in order to 
increase flexibility and reduce (van) costs, leading 
to the rising popularity of Web-based protocols such 
as HTTP (HyperText Transfer Protocol). However, 
process integration has not been a major consider¬ 
ation in interenterprise connectivity until quite re¬ 
cently. RosettaNet (Electronics 6 ) and cpfr (Collab¬ 
orative Planning, Forecasting, and Replenishment 7 ) 
are the first two to emphasize the importance of de¬ 
finitive process support in interenterprise collabo¬ 
ration. Today, it is generally acknowledged that a PTX 
platform should support end-to-end process collab¬ 
oration through the coordination of inter- and in¬ 
traenterprise processes. 

Second, a PTX platform requires the integration of 
many applications and systems as part of process col¬ 
laboration. In the past, integration of disparate ap¬ 
plications and systems was typically done through 
highly customized “hooks” with point-to-point links. 
This is not desirable from a development and main¬ 
tainability standpoint. Furthermore, these efforts in 
many cases assume the passive, or batch, mode of 
participation for these applications and systems in 
the overall solution. This assumption does not hold 
when a PTX solution requires invoking an applica¬ 
tion function in real time as part of the collabora¬ 
tion. The application integration technology in a 
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Table 1 Mapping of requirements to the platform characteristics 


Requirements 

Platform Characteristics 

Direct access, control, and connectivity 

Through a unified portal (PC3), user registration 
and management processes (PCI), and role- 
based access control (PC4) 

Sensitive data sharing to select 
partners 

By the role-based control (PC4) on business 
data object access (PCI, PC2) 

Enriched buy and sell capabilities 

Through a process (PCI) that spans multiple 
business units (intraenterprise) and trading 
partners (interenterprise), and application and 
data sources (PC2) belonging to these entities 

Business agreement-based 
collaboration 

By a collaborative process (PCI) with proper 
integration with business data and applications 
(PC2) based on the trading partner profile 
(PC4) supported by an interaction portal 
(PC3) 

Customizable services and processes 

Through a customization portal (PC3) specific to 
a particular trading partner (PC4) to define 
desired processes (PCI) coupled with 
applications and services (PC2) 

Event- and trigger-driven processing 

By monitoring events relating to solution 
execution (PCI, PC2, PC5) and triggering 
proper error/exception handling processes 
(PCI, PC5) through browser-based reports 
and other electronic notification methods 
(PC3) to predefined administrator roles (PC4) 


state-of-the-art PTX platform should support event- 
driven and interactive invocation of application func¬ 
tionality in a process execution context. 

Finally, a PTX platform must support complex bus¬ 
iness processes. Business objects (containing both 
data and logic) have been used to support the en¬ 
capsulation of complicated access to legacy systems 
so as to hide it from the application clients. It re¬ 
lieves the business processes from having to be con¬ 
cerned with the details of rigid legacy systems and 
legacy architectures. However, they still require the 
process clients to perform complex maintenance and 
control tasks, which reduces application maintain¬ 
ability and extensibility. Workflow management ad¬ 
dresses some, but not all of the issues. The new gen¬ 
eration of PTX platforms needs to support optimal 
business process management. 

These areas have developed independently over the 
years and accumulated a substantial amount of ap¬ 
plicable technology to address individual and sep¬ 


arate concerns. But the framework that brings all 
these together in a cohesive way to address the total 
PTX requirements and challenges is lacking. In this 
paper, we attempt to address this gap by introduc¬ 
ing a component framework for integration and col¬ 
laboration and proposing a new PTX platform based 
on this framework. 

The important role that the PTX platforms play in 
large companies’ overall enterprise computing strat¬ 
egies makes them one of few remaining bright spots 
in the enterprise software market. It is not surpris¬ 
ing that many independent software vendors (iSVs) 
are gearing up to serve this segment of the software 
market. We review several ISVs and discuss how they 
attempt to address the issues. 8-14 

webMethods 15 has two main products: webMethods 
Enterprise and webMethods B2B Integration Server. 
It focuses on the xml (Extensible Markup Language) 
-based B2B (business-to-business) collaboration that 
is supported by a suite of products acquired or in¬ 
ternally developed, ranging from an integration en- 
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gine and adapters to B2B management tool sets. Re¬ 
cently, it also added workflow management function 
to its product portfolio through an acquisition. The 
main challenges of using webMethods to build pri¬ 
vate exchanges are in the areas of transaction co¬ 
ordination and management, B2B partner manage¬ 
ment, and new adapter development for enterprise 
application integration. 

Vitria’s 16 main product is BusinessWare. Its under¬ 
lying products build on top of the Communicator, 
its CORBA* */iiop* * 17 bus. It stresses the importance 
of business process management in B2B automation 
and provides tools to support the definition, config¬ 
uration, and maintenance of business processes. The 
key challenges in using Vitria to develop private ex¬ 
changes involve workflow management, portal de¬ 
velopment, custom coding, and message transforma¬ 
tion. 

TIBCO 18 is moving from its messaging roots to be¬ 
come a B2B company. TIBCO has a strong reputation 
in the financial industry due to its affiliation with 
Reuters. It is a recognized enterprise application in¬ 
tegration (eai) company. Its main products include 
ActiveEnterprise for internal system and process in¬ 
tegration, ActivePortal for extending business pro¬ 
cesses to employees, customers, and suppliers, and 
ActiveExchange for connection with other trading 
partners and e-markets. The primary challenges of 
using TIBCO to build private exchanges include the 
integration issues (transformation, transactional and 
intelligent routing, and legacy access capability) and 
business process management. 

These examples are representative of the iSVs present 
in this market, but are far from exhaustive. Most of 
these vendors are strong in one area but weak in oth¬ 
ers. The goal of this paper is to present a compo¬ 
nent framework, based on design patterns, that ad¬ 
dresses all key issues in building private exchanges. 
The implementation of the framework could poten¬ 
tially make use of one or more of the ISV products 
available in the market. 

Our work draws from the existing work on design 
patterns and component frameworks 19-23 as well as 
electronic marketplaces. 24-31 In particular, the con¬ 
cepts introduced by Nayak et al., 23 Schmid and Lin- 
demann, 27 and Gawlick 28 have greatly influenced the 
design of the application platform discussed in this 
paper. Nayak et al. present the layered architecture 
of a virtual corporation management system with the 
capability for creating, operating, and eventually dis¬ 


solving virtual enterprises. Schmid and Lindemann 
describe the elements of a reference model for elec¬ 
tronic markets. Gawlick discusses the infrastructure 
for Web-based application integration. 

Interaction patterns 

The PTX and its participants may interact with each 
other in many different ways. The PTX portal serves 
as the single entry point for the trading partners to 
access all the browser-based PTX functions. Users of 
a PTX system may view business information (e.g., 
order status, inventory levels, forecast changes, etc.) 
or conduct more elaborate collaborations for var¬ 
ious supply chain processes (e.g., joint product sup¬ 
ply forecast, replenishment, and planning as exem¬ 
plified in cpfr) via the PTX portal. In this section, 
we capture the common interaction patterns within 
a PTX and categorize these patterns. These patterns 
build a foundation for our further discussions on the 
PTX platform. Figure 1 presents an overview of in¬ 
teraction patterns discussed in this section. 

We examine the interactions with the PTX from two 
dimensions: functional control and process collabo¬ 
ration. The first considers primarily what a partic¬ 
ipant can do on the PTX (e.g., information viewing, 
transaction control, etc.) while the other looks at how 
the PTX solutions handle the collaboration among 
the participants and system components through bus¬ 
iness process management. The identification of 
these patterns helps to crystallize the requirements 
and leads us to the framework and platform design. 

Functional control. The simplest function provided 
by a PTX is that of an information-viewing portal. This 
includes the rendering of both the business content 
and the status of transactions. Figure 2 illustrates this 
pattern. Beyond information viewing, a PTX usually 
allows certain forms of data!file exchange , e.g., down¬ 
load and upload of data via ftp (File Transfer Pro¬ 
tocol), messaging, EDI, or HTTPS (Secure HyperText 
Transfer Protocol). The data/file exchanges may in¬ 
volve direct server-to-server communications; Fig¬ 
ure 3 shows this pattern. In a more advanced form, 
a PTX permits the initiation and control of transac¬ 
tions, either manually or programmatically. An au¬ 
tomated process execution environment involving 
transaction management will require such a level of 
control. This pattern is illustrated in Figure 4. Table 
2 lists the interaction patterns in the functional con¬ 
trol category. 
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Figure 1 Overall interaction patterns 



ERP = ENTERPRISE RESOURCE PLANNING 
SCM = SUPPLY CHAIN MANAGEMENT 


Figure 2 Information viewing interaction pattern 
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Process collaboration. One of the main features of 
a PTX is the support of process collaborations, which 
can take many different forms. A process collabo¬ 
ration (see list in Table 3) can describe the inter¬ 
actions within the enterprise system’s components 
and role players ( intraenterprise , shown in Figure 5), 
among the exchange participants {interenterprise 
browser , shown in Figure 6), between the participants’ 
B2B servers and those of the PTX {interenterprisepro¬ 
gram , shown in Figure 7), or between other public 
or private exchanges and the PTX itself {collabora¬ 
tive, Figure 8). An actual PTX typically contains a 
combination of several such patterns to form end- 
to-end process collaboration. 


Platform description 

The patterns discussed in the previous section illus¬ 
trate the primary interactions among the role play¬ 
ers and system components exhibited in a typical PTX 
solution. These patterns provide the basic design con¬ 
siderations for the development of a component 
framework that serves as the foundation of the PTX 
platform. We call this the Process Broker framework, 
since the two principal functions are (1) brokering 
of multiple business processes encapsulated in var¬ 
ious back-end systems, including workflow engines 
and business applications, and (2) aggregating con¬ 
tent from multiple enterprise information systems, 
in the business context, and managing its shared ac- 
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Figure 3 Data/file exchanges interaction pattern 



HTTPS = HYPERTEXT TRANSFER PROTOCOL (SECURE) 
MQ = MESSAGE QUEUE 



Figure 4 Transaction control interaction pattern 
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cess based on the roles of participants. These two 
functions highlight the fundamental business process 
management capability of our PTX platform. 

The goal of the framework is to support rapid de¬ 
velopment of PTX solutions. It achieves this by cre¬ 
ating a brokering layer between the clients of the PTX 
and the enterprise systems. This layer maps service 
requests from the clients to appropriate enterprise 
systems, such as workflow engines, legacy applica¬ 
tions, ISV applications, and business objects. It sup¬ 
ports browser clients, facilitating human interaction 
with the system, as well as program clients that rep¬ 


resent business processes running external to the sys¬ 
tem. Major components of the framework are shown 
in Figure 9. 

We describe the framework using the fundamental 
design patterns 17 on which it is based. The Process 
Broker Facade component is designed based on the 
Fagade design pattern. Its purpose is to serve as an 
entry point for all client requests and to route them 
to the appropriate brokering components. The bro¬ 
kering components are called adaptive documents 
(ADocs). ADocs provide domain-specific and state- 
dependent service brokering by linking the content 
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Table 2 Interaction patterns- 

—functional control 



Types 

Characteristics 

Typical Examples 

Illustration 

Information viewing 

View general contents 

View transaction status 

Pricing, inventory and 
point-of-sales, 
order status 

Figure 2 

Data/file exchanges 

Exchange structured 
business data 
through the Web or 
other 

May use portal to 
download/upload or 
view transactions 

Simple: Up/download, 

FTP, etc. 

Sophisticated: HTTPS 
(HyperText 

Transfer Protocol- 
Secure), EDI, MQ 
(Message Queue) 

Figure 3 

Transaction control 

Control in-progress 
transactions 

Start, stop, pause, and 
restart transactions 

Transaction exception 
handling, automatic 
rollback, manual 
resent 

Figure 4 


Table 3 Interaction patterns- 

—process collaboration 



Types 

Characteristics 

Typical Examples 

Illustration 

Intraenterprise 

Between system components 
and role players within 
enterprise 

Purchase order validation 

Figure 5 

Interenterprise browser 

Between trading partners 
and the PTX 

Browser-based 

Collaborative planning, 
forecasting, and 
replenishment (CPFR), 
request for quote 
(RFQ) 

Figure 6 

Interenterprise 

program 

Between trading partners 
and the PTX 

B2B server-based 

RosettaNet PIPs, 
transportation planning 
and execution 

Figure 7 

Collaborative 

Between public e- 
marketplace/trading 
partner intranet and the 

PTX 

Purchases made at a 
public e-marketplace 
supported by the 
fulfillment processes 
via the PTXs of 
member companies 

Figure 8 


aggregated from various data sources to business 
processes and individuals. They support collabora¬ 
tive business process management through a vari¬ 
ety of applications and user interactions, in the con¬ 
text of a business process. For example, a purchase 
order ADoc supports collaboration between the 
buyer and supplier organizations in the context of 
procurement-related processes. ADocs are based on 


the State design pattern, 17 as they demonstrate state- 
dependent behavior. An ADoc implementation con¬ 
sists of an ADoc entity that captures the state in¬ 
formation and an ADoc controller that encapsulates 
the state-dependent ADoc behavior. The behavior 
is shared among all instances of an ADoc type. For 
example, all purchase orders exhibit the same be¬ 
havior and we need only one controller for the pur- 
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Figure 5 Intraenterprise interaction pattern 



Figure 6 Interenterprise browser interaction pattern 



chase order ADoc. An ADoc entity exists for each 
instance of an ADoc. Using the purchase order ex¬ 
ample, there is a purchase order ADoc entity for each 
purchase order in the system. 

The framework supports Web transactions by means 
of ADoc behavior. When a client issues a Web trans¬ 
action, it reaches some ADoc in the system as a ser¬ 
vice request. As defined in the behavior of the ADoc, 
the ADoc controller executes a set of actions deter¬ 
mined by the current state of the ADoc and the con¬ 
tents of the service request. These actions are im¬ 
plemented as a transaction. A service request may 
also result in changing the state of an ADoc. The 
fulfillment of a service request follows the Command 
design pattern. 20 There are three major participants 
in the Command design pattern: (1) A Command 
object declares an interface for executing an oper¬ 
ation. (2) A Concrete-Command object defines a 


binding between a Receiver object and an action. It 
implements a specific operation by invoking the cor¬ 
responding operations on a receiver. (3) A Receiver 
object knows how to perform the operations asso¬ 
ciated with a request. Any class may serve as a Re¬ 
ceiver class—commonly used receivers include work- 
flow engines, enterprise applications, business 
objects, and trading partner gateways. 

The Process Broker framework is used to realize two 
key functional modules in the platform as shown in 
Figure 10: (1) the business flow manager (bfm) mod¬ 
ule that manages the internal (private) business pro¬ 
cesses of the enterprise hosting the PTX, and (2) the 
interaction manager (im) module that manages the 
external (public) processes the enterprise exposes to 
its trading partners. These external processes include 
both browser and program interfaces. The PTX por- 
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Figure 7 Interenterprise program interaction pattern 



Figure 8 Collaborative interaction pattern 



tal discussed earlier is facilitated by the interaction 
manager component. 

These two modules are positioned on top of a base 
service layer to realize the ptx platform. The base 
layer consists of the following core services: 

• Messaging services, which provide XML-based 
asynchronous communication support including 
message brokering, transformation, translation, ag¬ 
gregation, splitting, routing, and publish/subscribe. 
Java** Messaging Service (jms) 32 is used as the 
interface to integrate BFM and IM modules with 
the messaging services provider. 

• Solution management services, which include au¬ 
dit, exception handling, and monitoring of busi¬ 
ness processes. Java reliability and availability ser¬ 
vices (jras) and Java Management Extensions 
(jmx) 28 are used to define the interface between 


the IM and BFM modules and the solution man¬ 
agement service provider. 

• Authentication and authorization services, which 
include security, directory support, and role-based 
access control to the ptx functions. This interface 
is based on the Java Authentication and Autho¬ 
rization Service. 33 

The platform includes a build-time suite of tools 
called Private Exchange Solution Builder. The so¬ 
lution builder enables creation and customization of 
PTX solution instances. The high-level component 
architecture of the platform is shown in Figure 10. 
“ptx Solution” refers to an actual private exchange 
solution implemented on the platform, which is dis¬ 
cussed in detail later. 

The internal processes of a PTX typically involve 
workflow. The business flow manager module in- 
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eludes a workflow services component that augments 
the Process Broker framework. The process broker 
interacts with the workflow services layer via activ¬ 
ity controllers. An activity controller is defined for 
each node in a workflow graph. The activity control¬ 
lers are defined exactly the same way as ADoc con¬ 
trollers, using the State and Command design pat¬ 
terns. 

A business transaction may need to interact with sev¬ 
eral concurrent workflow processes, and an ADoc 
is responsible for the choreography of these pro¬ 
cesses. An ADoc controller is associated dynamically 
with activity controllers to effect workflow choreog¬ 
raphy. For each workflow process involving an ADoc, 
a corresponding activity controller is associated with 
the ADoc controller. 

The interaction manager uses the process broker 
framework to implement trading partner protocols 
and public processes. For example, the RosettaNet 
PIP* * (Partner Information Process) for purchase or¬ 
der processing 6 is implemented using an ADoc in 
the interaction manager. Additionally, it provides 
connection services, session management, and sin¬ 
gle sign-on (SSO). The ADocs in the interaction man¬ 
ager use the Process Broker Fagade object of the 
business flow manager as a receiver to transmit cli¬ 
ent transactions into the enterprise. 

Platform implementation 

The implementation of the private exchange plat¬ 
form is based on IBM WebSphere* Business Inte¬ 
grator (wbi). 2 WBI is a complete application plat¬ 
form that allows the design, development, and 
deployment of intra- and interenterprise business 
processes. In addition to the interaction manager and 
business flow manager modules discussed earlier, 
WBI includes the following: solution manager for so¬ 
lution management services, trust and access man¬ 
ager for security and directory services, partner 
agreement manager for B2B connectivity services, and 
information delivery manager for messaging services. 

The WebSphere Business Integrator programming 
model is based on the IBM Application Framework 
for e-business. 34 WBI brings together several IBM 
products to provide a cohesive, prescriptive approach 
to creating e-business solutions. Table 4 shows the 
specific IBM products 35-38 used to implement the ptx 
platform modules within WBI. 


Figure 9 Process broker framework 



Figure 10 Components of the PTX platform 



BASE SERVICES 

SOLUTION MANAGEMENT, SECURITY, 
DIRECTORY, MESSAGING 


The process broker framework is implemented as 
an Enterprise JavaBeans** (ejb**) 39 application on 
the WebSphere Application Server. Clients commu¬ 
nicate with the process broker in one of two ways: 
(1) synchronously using RMI (Remote Method In¬ 
vocation) over HOP or (2) asynchronously via XML 
messages to a JMS listener in the WebSphere Ap¬ 
plication Server. Similarly, the process broker com¬ 
municates with other systems either synchronously 
using RMI over HOP or asynchronously via XML mes¬ 
sages. 
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Figure 11 Components of a process template 
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Table 4 IBM products used in the PTX platform implementation 


PTX Platform Module 

IBM Product 

Interaction manager 

WebSphere Application Server, 

WebSphere Portal Server 

Business flow manager 

WebSphere Application Server, 

MQSeries*, MQ Workflow 

Trust and access manager 

Tivoli Secure Way LDAP Server and Policy 

Director 

Information delivery manager 

MQSeries Integrator, MQ Adapter 

Offerings 

Solution manager 

Tivoli eMarketplace Manager 


Solution example 

In this section, we describe the implementation of 
a PTX solution on the platform, derived by custom¬ 
izing a PTX solution template. A solution template 
consists of a set of predefined process templates, 
brought together by the process broker. For exam¬ 
ple, a simplified PTX solution template for the dis¬ 
tribution industry may be composed of three pro¬ 
cess templates: cpfr, rfq (request for quote), and 
PO (purchase order)/invoicing. 

Figure 11 shows the internal structure of a process 
template. The components are: 

• Process orchestrator. This is built on the ADoc con¬ 
cept discussed earlier. A process orchestrator may 
contain multiple ADocs, which implement the in¬ 
ternal business processes of the private exchange 


and are deployed in the business flow manager 
module. 

• Activity map. For each activity, an activity map lists 
the set of activities to be activated upon its com¬ 
pletion. This set may be generated dynamically at 
run time or statically defined at build time. In some 
cases, only the activity names are defined at build 
time and the cardinality is determined at run time. 
The activity maps define the workflows and are de¬ 
ployed in the workflow engine. 

• Process adapter. This is a specialized ADoc that 
handles program-to-program communications be¬ 
tween enterprises. Process adapters are deployed 
in the interaction manager module. 

• Business objects. These are domain-specific objects 
that serve as receivers to the commands in the con¬ 
trollers. They include application adapters that 
connect to legacy applications, as well as new corn- 
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ponents developed to cover “white space” func¬ 
tions in the solution. 

• Views. Users participate in the business process 
through ADoc views, which have three compo¬ 
nents: action, navigation, and content. The action 
corresponds to the dynamic business services that 
are exposed by an ADoc, depending on the role 
of the user and the context of the business pro¬ 
cess, and invoked via the Process Broker Facade 
interface. The navigation can be either process-cen¬ 
tric (e.g., the set of actions given the current pro¬ 
cess state) or document-centric (e.g., the list of 
ADocs that require some action). The ADoc sup¬ 
ports both navigation models, which are accessed 
via the Process Broker Facade interface. The con¬ 
tent in the view is marshaled by the execution of 
the business services in an ADoc, i.e., the business 
transactions that are brokered by the ADoc con¬ 
trollers to aggregate the content from a multitude 
of back-end sources, such as applications, business 
objects, and databases. 

Figure 12 shows an actual RFQ template, without the 
views. Typically, the template will include the views 
for each role player who is a collaborator in the pro¬ 
cess. The template has no process adapters, because 
there are no program-to-program communications 
across the enterprise boundaries for this process. The 
artifacts in the template include an ADoc Entity ob¬ 
ject that maintains the ADoc state, an ADoc con¬ 
troller, activity controllers, activity maps, commands 
used by the controllers, and receivers. The artifacts 
shown in gray are provided as part of the PTX plat¬ 
form, while the other artifacts are created as part of 
the RFQ process template. 

The RFQ ADoc, including the RFQ ADoc entity and 
RFQ ADoc controller, all the commands, and all the 
activity controllers in Figure 12 map to the Process 
Orchestrator part of the process template. The “RFQ 
Processing” and “Quote Create” macro flows map 
to the Activity Map in the template. These flows are 
shown in more detail in Figure 13. The receivers 
(RFQ Business Object [bo], etc.) map to the business 
objects in the template. 

Figure 14 shows the RFQ ADoc controller state ma¬ 
chine. The states of the RFQ ADoc, the transitions 
allowed at each state, the event that triggers each 
transition, and the commands invoked as part of the 
transition are shown. 

There are five activity controllers in the RFQ Pro¬ 
cess template. Figure 15 shows the activity control¬ 


ler for the “Evaluate Response” activity. All activ¬ 
ities have an “Available” state, a “Claimed” state, 
and a “Complete” state. Additional states may be 
added as demanded by the micro workflow associ¬ 
ated with an activity. 

Experience and evaluation 

We have used the platform to build proof-of-con- 
cept private exchange solutions for several custom¬ 
ers from diverse industry segments, including 
aerospace, automotive, retail, and electronics. Our 
experience in building these solutions has underlined 
the versatility of the platform for the rapid assembly 
of B2B e-commerce solutions. In this section, we re¬ 
visit the requirements for building a PTX exchange 
solution and evaluate the platform against them. 

For illustration, we use a sample PTX implementa¬ 
tion based on real-world PTX solutions developed for 
our customers. The solution template is made up of 
three process templates, as discussed in the previ¬ 
ous section. We focus on the RFQ and PO processes 
here. The RFQ process starts with a buyer, in the com¬ 
pany that hosts the PTX, issuing an RFQ request 
through the PTX portal. The suppliers use the portal 
to respond to the RFQ, the PTX system aggregates 
the responses and presents them to the buyer for sup¬ 
plier selection, and the process ends with a PO trans¬ 
action between the PTX and the supplier system. 

Figure 16 shows the detailed sequence diagram for 
this process. The boxes refer to three types of com¬ 
ponents: platform components, solution compo¬ 
nents, and users or partner systems. Supplier and 
buyer boxes represent the users with the correspond¬ 
ing roles. “Buyer program” represents an informa¬ 
tion technology system in the buyer enterprise. Gate¬ 
way and IM components in the figure map to the 
interaction manager in Figure 10. AM, log server, and 
BO messaging service components in Figure 16 map 
to the base services in Figure 10. The BO and SAP** 
adapter boxes in Figure 16 are parts of the PTX so¬ 
lution. bfm and JAWS** boxes map to the bfm com¬ 
ponent in Figure 10. IM and BFM boxes in Figure 16 
represent parts of the PTX solution, in addition to 
the platform components. 

Now we revisit the requirements introduced earlier 
and demonstrate how they are addressed by the plat¬ 
form. 

Direct access, control, and connectivity. This im¬ 
plementation provides two primary mechanisms for 
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Figure 12 An RFQ process template 
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Figure 13 Activity maps for RFQ processing (above) and quote creation (below) in the RFQ process template 




trading partners to connect to the PTX: (1) browser- 
based access via the portal, and (2) programmatic 
access via a gateway component. In either case, the 
access manager component provides security service 
in the platform, by authenticating the user. Addition¬ 
ally, the access manager identifies the user’s role 
(buyer or supplier). The role information is used for 
access control—the user can access only those sys¬ 
tem resources authorized for the role. The interac¬ 
tion manager uses this information to render a role- 
specific view of the portal (supplier portal or buyer 
portal) and the business flow manager uses it give 
user-selective access to system functionality in the 
management of the entire RFQ process. For the PO 
transaction, the supplier systems connect with the 
PTX gateway for program-to-program data exchange. 
A public process and an associated protocol defined 
between the PTX and the trading partner manage this 


exchange. The ADoc technology is used to imple¬ 
ment this public process and the protocol. 

Sensitive data sharing with select partners. As just 
described, the platform has total control over what 
business data the users can see and which system 
functions they can invoke. The user security profile 
(roles and access control list) determines this. In the 
RFQ example, only the buyer can view the responses 
from all the suppliers; the competing suppliers can 
view only their own quotes. The RFQ ADoc realizes 
this constraint by permitting only the buyer who ini¬ 
tiated the RFQ to view the responses from the sup¬ 
pliers. 

Enriched buy and sell capabilities. The platform al¬ 
lows the integration of distributed and fragmented 
data in the context of the RFQ process. For instance, 
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Figure 14 RFQ ADoc controller state machine 
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Figure 15 Activity controller for “Evaluate Response” 
activity 
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the lead time and the supplier performance history 
can help the buyer in the quote evaluation and sup¬ 
plier selection process. This is realized through the 
information integration capability of the activity con¬ 
troller that executes the supplier selection micro 
workflow (the supplier performance data may be 
stored in a separate system or database). 


Business agreement-based collaboration. The bus¬ 
iness agreements are externalized and captured in 
the form of a trading partner agreement. The platform 
uses ADocs to implement these agreements and 
drive collaborative processes based on them. For ex¬ 
ample, the platform can support RosettaNet proto¬ 
col for the PO process with one supplier and a non¬ 
standard vendor-specific protocol with another. 

Customizable services and processes. The system 
provides differentiated services and processes by cap¬ 
turing service and process definitions in a trading 
partner profile, managed by the access manager 
module. The IM and BFM modules access this infor¬ 
mation to tailor system behavior to match user pref¬ 
erences. As an example, the RFQ notification meth¬ 
ods available to the supplier community may vary 
based on supplier preference (i.e., some may want 
e-mail notification while others may prefer a pro- 
gram-to-program RFQ transaction). The trading part¬ 
ner profile includes this type of information. 

Event- and trigger-driven processing. The realiza¬ 
tion of an ADoc as a state machine with event-driven 
state transitions supports an event-driven program¬ 
ming model. 

Concluding remarks 

The platform proposed in this paper addresses many 
of the challenges in the development of state-of-the- 
art PTX solutions. We conclude with a discussion of 
the outstanding issues, some of which are being ad¬ 
dressed by our own ongoing work in this area. 

Partner enablement is critical to the success of a pri¬ 
vate exchange. Unless the trading partners of a com¬ 
pany are able to connect and transact using the PTX 
platform, the business benefits of a PTX solution are 
not materialized. Typically, the onus of bringing the 
partners on board rests with the hosting company. 
Hence, the PTX platform needs to provide the tools 
that make it easy for trading partners to come on 
board. This is a hard problem because of the vari¬ 
ability in the participants’ capabilities and sophisti¬ 
cation in the required technologies. Adding to the 
complexity is the need for a set of customized fea¬ 
tures and functions to be presented for each part¬ 
ner. The tools should facilitate the customization of 
business rules, processes, and workflows for each par¬ 
ticipant. Our current work attempts to solve this 
problem by creating a “service provisioning” com¬ 
ponent in the platform that alleviates some of the 
difficulties in bringing a new trading partner on 
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Figure 16 Sequence diagram for a sample PTX RFQ 
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board. This component uses Web services technol¬ 
ogy and standards to accelerate partner enablement. 

We have briefly mentioned the PTX Solution Builder 
as the build-time component of our platform. Cur¬ 
rent implementation of this module is too low-level, 
requiring J2EE** (Java 2 Platform, Enterprise Edi¬ 
tion) development skills to create or customize a so¬ 
lution template. We are working on a high-level 
meta-model to describe the solution template and 
associated tools, which can be used without program¬ 
ming skills to develop and customize a solution. 


Another area that needs work is solution-centric 
management of the PTX solution. The solution man¬ 
agement component needs to be enhanced to man¬ 
age the service level agreements (SLAs) that the com¬ 
pany has with its trading partners. Auditing 
information at various levels—system level, trans¬ 
action level, application level, process level—are 
needed for effective SLA management. The audit log 
is an excellent source for business intelligence as well. 
We are currently working on an agent-based PTX sys¬ 
tem that exploits workflow audit logs for intelligent 
trading partner management. 
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